The present invention relates to methods and systems for implementing a real-time, distributed, hierarchical database. More particularly, the present invention relates to methods and systems for implementing a real-time, distributed, hierarchical database using a proxiable protocol.
Classical high performance telephony data structures, such as home location registers (HLRs), number portability databases, visitor location registers (VLRs), and other subscriber-services-related data structures require reliable, real-time access databases. Existing data structures rely on large centralized databases implemented in fault-tolerant computing platforms. Implementing large data structures results in costly, inflexible products, and network architectures.
FIG. 1 illustrates a conventional centralized database architecture. In FIG. 1, a subscriber might desire to make a call to another subscriber whose number has been ported from one carrier to another carrier. When the subscriber dials the number using end user device 100, which can be a public switched telephone network (PSTN) terminal, the dialed digits are communicated to service switching point (SSP) 102. SSP 102 is a switch at the calling subscriber""s end office that sets up a call with a called party through the called party""s end office. SSP 102 examines the dialed digits and determines that the number has been ported. Accordingly, SSP 102 formulates a transaction capabilities application part (TCAP) query and addresses the query to service control point (SCP) 104. The TCAP query passes through signal transfer point (STP) 106, which routes the query to SCP 104. SCP 104 includes a centralized database containing contact numbers corresponding to ported numbers. SCP 104 performs a database lookup using the dialed digits and determines a contact number corresponding to the ported number. SCP 104 sends the contact number to SSP 102 through STP 106 in a TCAP response. SSP 102 then sends a call setup message to the end office corresponding to the contact number in order to establish a call.
One problem with the centralized database architecture illustrated in FIG. 1 is that the centralized database in SCP 104 is required to contain entries for all ported numbers. Large database structures cannot be economically implemented by SCP 104. For example, a database can require 20 million records for number portability or other service. In order to provide a real-time response, e.g., 5 milliseconds or less, the entire database is required to be stored in dynamic random access memory (RAM) of a central processing unit (CPU) engine. The amount of RAM required to store 20 million database records greatly increases the cost of a centralized database. For example, 1 Gigabyte of RAM can be required to store 5 million subscriber database records. Current technology only allows 1 Gigabyte of RAM to be present on a single Versa Module Europa (VME) bus board. As a result, multiple VME bus boards with multiple processors are required to implement a database of 20 million customer records. Similar memory limitations exist in other board technologies such as Compact PCI. Such memory and processing requirements are cost-prohibitive for a single SCP database. What is needed is a real-time, distributed, hierarchical database in which database records are distributed across multiple physical machines located in different locations. Such a database preferably appears as a single database to the database user so that no modifications are required to existing telephony equipment, such as end office switches and gateways that access the databases. Accordingly, there exists a need for novel methods and systems for implementing a real-time, distributed, hierarchical database in a manner that is transparent to the database user.
The present invention provides novel methods and systems for implementing a real-time, distributed, hierarchical database using a proxiable protocol. As used herein, the phrase xe2x80x9cproxiable protocolxe2x80x9d refers to any protocol used to send call signaling messages over an IP network in which one entity can act as a proxy for another entity in performing a desired function. For example, if one entity is unable to respond to a request from a telephony device, that entity can proxy the request by sending a second request to another entity that is capable of responding. The second request includes all of the information in the first request, but specifies that the response to the second request is to be sent to the first entity, rather than the original requester. When the first entity receives the response, the first entity responds to the requester as if the first entity had obtained the data. In this manner, the number of entities can be increased arbitrarily and transparently to the requester.
One example of a proxiable protocol is the session initiation protocol (SIP), as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2543: Session Initiation Protocol, March 1999, the disclosure of which is incorporated herein by reference in its entirety. SIP is an application layer control protocol that is conventionally used to establish, modify, and terminate multimedia sessions or calls. SIP provides proxiable messages used to perform call setup, modification, and termination functions. For example, one SIP message used to perform call setup functions is the INVITE message. The INVITE message is conventionally used to invite telephony devices to participate in a media stream communication, such as a voice communication, a data communication, a video communication, or any combination thereof. The INVITE message includes a session description protocol (SDP) portion that is used by end user devices to exchange media capabilities and other information. One entity that formulates and processes INVITE messages, as well as other SIP messages, is referred to as a proxy server. As defined in the SIP protocol, a proxy server is an entity that is capable of acting as a proxy or agent for another entity. For example, a proxy server can receive a request, interpret the request, and formulate a new request on behalf of the original requester. Thus, a SIP proxy server is capable of proxying INVITE messages for entities, such as SIP clients and other proxy servers functioning as SIP clients. Each proxy server in the chain of proxy servers includes its own via header in the INVITE message. The via headers specify a return path for the response that is the same as the request path. According to one aspect of the present invention, this proxying and return-path specifying capability of SIP is utilized in a novel way to implement a real-time, distributed, hierarchical database.
The present invention is not limited to SIP proxy servers. Any suitable proxy server that is capable of proxying requests for other entities and specifying a return path is intended to be within the scope of the invention.
Embodiments of a real-time, distributed, hierarchical database described below can be implemented in hardware, software, or a combination of hardware and software. Accordingly, it is understood that embodiments of the present invention can be implemented as computer-executable instructions embodied in a computer-readable medium for performing the steps described below for implementing a real-time, distributed, hierarchical database. Exemplary computer-readable media suitable for use with the present invention include magnetic and optical disk storage devices and electrical storage devices, such as chip memory devices.
Accordingly, it is an object of the present invention to provide novel methods and systems for implementing a real-time, distributed, hierarchical database using a proxiable protocol.
An object of the invention having been stated hereinabove and which is achieved in whole or in part by the present invention, other objects will be evident as the description proceeds, when taken in connection with the accompanying drawings as best described hereinbelow.